Add `register_peer_for_interception()` and
`deregister_peer_for_interception()` methods to `OnionMessenger`,
allowing specific peers to be registered for onion message interception
without enabling blanket interception for all offline peers.

When a registered peer is offline and an onion message needs to be
forwarded to them, `Event::OnionMessageIntercepted` is emitted. When
a registered peer connects, `Event::OnionMessagePeerConnected` is
emitted. This works alongside the existing global
`new_with_offline_peer_interception()` flag — if either the global flag
is set or the peer is specifically registered, interception occurs.

This enables LSPS2 services to intercept onion messages only for peers
with active JIT channel sessions, rather than intercepting messages for
all offline peers.

Co-Authored-By: HAL 9000

Define the `OnionMessageInterceptor` trait with
`register_peer_for_interception()` and
`deregister_peer_for_interception()` methods, and implement it for
`OnionMessenger`. This allows external components to register peers
for onion message interception via a trait object, without needing
to know the concrete `OnionMessenger` type.

Wire the trait into `LSPS2ServiceHandler` as an optional
`Arc<dyn OnionMessageInterceptor>`. When provided:
- On init, all peers with active intercept SCIDs are registered
- In `invoice_parameters_generated()`, the counterparty is registered
  when a new intercept SCID is assigned

This ensures that onion messages for LSPS2 clients with active JIT
channel sessions are intercepted when those clients are offline,
enabling the LSP to store and forward messages when the client
reconnects.

Co-Authored-By: HAL 9000

When intercept SCIDs are removed during cleanup, also clean up the
handler-level `peer_by_intercept_scid` map and deregister the peer
from onion message interception if they have no remaining active SCIDs.

Cleanup is added in all relevant paths:
- `prune_expired_request_state()` now returns pruned SCIDs
- `peer_disconnected()` cleans up after pruning
- `htlc_intercepted()` error path (fixes existing TODO)
- `channel_open_abandoned()` cleans up after removing the SCID
- `persist()` cleans up both `peer_by_intercept_scid` and
  `peer_by_channel_id` when removing a peer entry entirely

Co-Authored-By: HAL 9000

…aths

Add a test that verifies the `manually_handle_bolt12_invoice_requests`
config flag and `send_bolt12_invoice_for_intercept_scid` convenience
method work correctly together. The test exercises the full LSPS2+BOLT12
flow: creating an offer, receiving an `InvoiceRequest` via the
`Event::InvoiceRequestReceived` event, building a BOLT12 invoice with
blinded payment paths using an intercept SCID, and sending the invoice
back to the payer via onion message.

Co-Authored-By: HAL 9000

Add `bolt12_lsps2_end_to_end_test` that exercises the full BOLT12 + LSPS2
JIT channel lifecycle across three nodes (payer, service/LSP, client):

- LSPS2 ceremony to negotiate JIT channel parameters
- Client creates BOLT12 offer with `manually_handle_bolt12_invoice_requests`
- Payer sends `InvoiceRequest` routed through the service via onion messages
- Client handles `InvoiceRequestReceived` and calls
  `send_bolt12_invoice_for_intercept_scid` to create an invoice with blinded
  payment paths through the service's intercept SCID
- Payer pays the invoice through the blinded path
- Service intercepts the HTLC and opens a JIT channel to the client
- Client claims, service broadcasts the funding transaction

Co-Authored-By: HAL 9000